昨天寫到最後，我留下了一個問題：
Prompt 跟 Requirement，到底差在哪裡？
如果最後都是透過自然語言跟 AI 溝通，那這個問題其實會變得更直接：
把 Prompt 寫得很完整，跟把 Requirement 寫清楚，到底有什麼不一樣？
一開始我其實也會把這兩件事混在一起。
想到更多功能，就繼續補進 Prompt。
AI 做錯了，就把 Prompt 改得更詳細。
畫面不符合期待，就加入更多 UI 描述。
久了之後，Prompt 可能從原本的一句話，變成好幾百字甚至上千字。
看起來越來越完整。
但問題是：
Prompt 變完整了，需求真的也變清楚了嗎？
繼續用昨天的「活動報名網站」來看。
一開始，我可能只對 AI 說：
幫我做一個活動報名網站。
很明顯，這句話留下了大量空白。
所以我開始補充：
幫我做一個活動報名網站，使用 React 和 Tailwind CSS 開發。首頁要有活動名稱、活動介紹、日期、地點以及報名按鈕。使用者點擊報名後進入表單，填寫姓名、Email 和電話，送出之後顯示報名成功頁面。整體介面希望簡潔、現代，而且要支援手機版。
這次看起來好多了。
技術有了。
頁面有了。
欄位有了。
流程也大致有了。
如果把這段交給 AI Coding 工具，它大概已經可以開始產生一個看起來像模像樣的網站。
但再多想一下，就會發現還是有很多事情沒有決定。
例如：
報名有沒有人數上限？
額滿之後按鈕要消失，還是顯示「已額滿」？
同一個 Email 可以重複報名嗎？
活動開始之後還能不能報名？
電話是不是必填？
Email 格式錯誤時要怎麼處理？
報名成功之後，要不要寄確認信？
使用者填完表單後能不能修改資料？
如果送出失敗，要顯示什麼？
這些問題，跟 React、Tailwind、按鈕圓角多大，其實是完全不同層次的事情。
而且它們會直接影響最後做出來的產品怎麼運作。
這也是我慢慢發現：
Prompt 裡面的字變多，不代表那些真正需要決定的事情已經被決定了。
我目前會把 Prompt 理解成：
在這一次互動裡，我要怎麼把任務、背景、限制與期待告訴 AI。
所以 Prompt 關心的是「怎麼溝通」。
例如我可以告訴 AI：
這些資訊都可能讓 AI 更容易理解我要它做什麼。
因此，Prompt 當然很重要。
尤其到了 Vibe Coding，Prompt 幾乎已經變成人跟程式碼之間的重要介面。
但問題在於：
如果我自己都還沒有決定產品應該怎麼運作，再好的 Prompt 也只是把「還沒決定的事情」更清楚地交給 AI。
Requirement 關心的是另一件事：
這個系統真正需要滿足什麼？
例如剛剛的活動報名網站。
「使用 React 開發」是一種技術上的指示。
但：
每個 Email 只能報名一次。
這是在決定系統行為。
再例如：
活動額滿後，使用者仍然可以查看活動資訊，但不能再送出報名表單。
這也是在決定產品應該如何運作。
甚至：
使用者沒有登入帳號也可以完成報名。
這同樣會直接改變整個產品設計。
這些決定就算今天不是交給 ChatGPT、Claude 或其他 AI Coding 工具，而是交給一位工程師開發，它們依然必須被說清楚。
這就是我目前認為 Prompt 與 Requirement 最重要的差別。
Prompt 關心的問題是「我要怎麼告訴 AI？」，對象是 AI 模型或 AI Coding 工具本身，內容通常是任務、背景、格式、技術指示這些東西。Requirement 關心的問題不一樣，是「產品應該滿足什麼？」，對象其實是專案本身，內容比較偏向使用方式、規則、限制、預期行為。
差別在換掉 AI 的那一刻會更明顯：如果哪天換一個模型或工具，Prompt 大概要重新調整；但 Requirement 原則上還是成立的。沒寫清楚的後果也不一樣——Prompt 沒寫清楚，AI 可能不懂你在講什麼；Requirement 沒寫清楚，AI 就只能自己替你做產品決定了。
這兩者並不是互斥的。
一個好的 Prompt 當然可以包含很完整的 Requirement。
差別大概是這樣：
我想傳達的「內容」是 Requirement，Prompt 只是我拿來把這些內容交給 AI 的其中一種「方式」。
這件事也是我開始做 ClarifyBuild 之後，覺得特別需要分清楚的地方。
因為現在很多人在改善 Vibe Coding 結果時，很自然會想到：
是不是我的 Prompt 不夠好？
於是開始研究 Prompt 要怎麼寫得更完整。
加入角色。
加入背景。
加入技術架構。
加入 UI 風格。
加入輸出格式。
甚至建立一份非常長的 Master Prompt。
這些方法本身都沒有問題。
但如果真正缺少的是「產品決定」，那麼光靠改寫 Prompt，其實沒有解決根本問題。
假設我寫：
請你扮演一位具有十年經驗的 Senior Full-Stack Developer，仔細分析以下需求，使用 React、TypeScript 與 Tailwind CSS 建立一套具有良好 UX、RWD、可維護架構與現代化視覺設計的活動報名系統……
這段 Prompt 聽起來非常專業。
但它仍然沒有告訴 AI：
同一個人能不能報兩次？
如果我沒有決定，AI 還是只能自己決定。
可能第一次幫我做成可以重複報名。
我發現不對之後，再告訴它不能重複。
接著 AI 又開始修改表單驗證、資料結構和錯誤訊息。
如果這個決定還牽涉到其他功能，就可能繼續往後改。
於是又回到 Day 2、Day 3 一直談到的情況：
Coding 很快，但返工也很快。
這也是我目前對 Vibe Coding 最大的觀念轉變之一。
以前寫程式時，很多事情必須自己處理，因此會被迫提早思考。
資料怎麼存？
狀態怎麼變？
錯誤怎麼處理？
使用者下一步去哪裡？
但現在 AI 可以非常快速地幫我補完這些東西。
這當然讓開發速度快很多。
可是另一面是：
過去會阻止我繼續 Coding 的問題，現在 AI 可以直接幫我跨過去。
而它跨過去的方法，就是幫我選一個答案。
這個答案不一定錯。
有時甚至非常合理。
真正的問題是：
那是不是我想要的答案？
如果不是，我可能要等到功能已經做出來，甚至整套流程都建立之後才發現。
所以我現在會把問題分成兩種：
一種是：
這件事情要怎麼實作？
這類問題通常很適合跟 AI 一起解決。
另一種則是：
這個產品應該怎麼運作？
這類問題，我反而希望在 AI 開始寫程式之前，就先被提出來。
因為後者其實跟怎麼寫程式沒什麼關係，是決策的問題。
這個差異也慢慢影響了 ClarifyBuild 的定位。
如果問題只是：
使用者的 Prompt 寫得不夠好。
那 ClarifyBuild 最簡單的做法，其實就是做一個 Prompt Optimizer。
使用者輸入：
幫我做一個活動報名網站。
系統幫他改寫成一段幾百字、格式漂亮、技術細節完整的 Prompt。
然後直接丟給 AI Coding 工具。
這當然也有價值。
但它不是我現在真正想解決的問題。
我更在意的是：
當使用者只有一個 Idea 時，有哪些重要的事情其實還沒有被決定？
所以 ClarifyBuild 不應該只是把原本的句子「寫得更專業」。
它應該先停在 Coding 前面，去找出藏在一句 Idea 裡、還沒被問出來的問題。
例如：
「幫我做一個活動報名網站。」
ClarifyBuild 不應該第一時間回答：
好，我幫你整理成最佳 Prompt。
而應該先問：
一個人可以重複報名嗎？
有報名人數限制嗎？
活動額滿後要發生什麼事？
報名需要登入嗎？
因為這些答案，才會真正改變後面要做出什麼。
所以走到 Day 4，我目前對整件事情的理解開始變成：
我們當然需要更好的 Prompt。
但在更好的 Prompt 之前，也許還需要先確認：
我到底有沒有把需求想清楚？
如果需求本身還是一堆尚未回答的問題，那麼直接進入 Prompt Engineering，很可能只是把模糊需求包裝得更完整。
這也是 ClarifyBuild 想插入的位置：在 Idea 真正交給 AI Build 之前，多留一個 Clarify 的步驟。它不是要取代 Prompt，也不是要取代 AI Coding，只是想在兩者前面，多留一段真正想清楚的時間。
目前整條路徑也開始慢慢成形：
Idea → Clarify → Requirement → Specification → Build
一個模糊的想法，不直接變成程式碼。
而是先經過澄清，逐步變成真正能夠支撐開發的資訊。
至於這個 Clarify 到底要怎麼做？
ClarifyBuild 又應該問使用者哪些問題？
這就會開始進入下一階段真正要設計的東西了。
今天想留下的是這個差異：
Prompt 負責的是我跟 AI 怎麼溝通，但產品到底要做什麼，還是得先把 Requirement 想清楚。
Prompt 可以很長。
可以很完整。
甚至可以寫得非常專業。
但如果真正重要的產品決定還沒有做出來，AI 最後仍然必須替我們填空。
而我現在想做的 ClarifyBuild，並不是讓 AI 更會猜。
而是想辦法讓：
需要猜的地方變少。
明天開始，就要從「發現問題」慢慢走向「怎麼解決問題」。
也要正式把 ClarifyBuild 拉進來看看：
從一個模糊 Idea 出發，它應該怎麼一步一步把需求問清楚？
Day 4 完成。
明天見。
iThome鐵人賽
看影片追技術